Providing e-receipts to customers

ABSTRACT

Embodiments of the invention relate to systems, methods, and computer program products for providing e-receipts to customers. Embodiments receive authorization from a customer for the customer to be enrolled in a point of transaction e-receipt communication program; receive transaction data corresponding to at least one transaction performed by the customer at a point of transaction of a merchant; and initiate communication, to the customer, of an e-receipt based at least in part on the received transaction data. Some embodiments receive authorization from a plurality of enrolling merchants for enrollment in the point of transaction e-receipt communication program; and build a cooperating merchant list comprising information corresponding to a plurality of cooperating merchants cooperating with a financial institution implementing the point of transaction e-receipt communication program.

BACKGROUND

Financial institutions desire to provide appropriate and helpfulguidance to customers regarding their financial affairs. One way thatfinancial institutions assist customers is by facilitating onlinebanking transactions, such as online transfers, online bill pays,purchases of stocks or bonds, and other types of online bankingtransactions. Financial institutions are continually seeking new andinnovative methods of improving the customer experience, including thecustomer experience of online banking transactions.

SUMMARY

The following presents a simplified summary of one or more embodimentsof the invention in order to provide a basic understanding of suchembodiments. This summary is not an extensive overview of allcontemplated embodiments, and is intended to neither identify key orcritical elements of all embodiments, nor delineate the scope of any orall embodiments. Its sole purpose is to present some concepts of one ormore embodiments in a simplified form as a prelude to the more detaileddescription that is presented later.

According to an embodiment of the invention, a financial institutionsystem for providing e-receipts to customers includes a computerapparatus including a processor and a memory; and a software modulestored in the memory, comprising executable instructions that whenexecuted by the processor cause the processor to receive authorizationfrom a customer for the customer to be enrolled in a point oftransaction e-receipt communication program; receive transaction datacorresponding to at least one transaction performed by the customer at apoint of transaction of a merchant; and initiate communication, to thecustomer, of an e-receipt based at least in part on the receivedtransaction data.

In some embodiments, the executable instructions further cause theprocessor to request authorization from the customer for the customer tobe enrolled in the point of transaction e-receipt communication program.

In some embodiments, the transaction data is received as an e-receiptgenerated by the merchant and based on the at least one transactionperformed by the customer at the point of transaction of the merchant.

In some embodiments, the executable instructions further cause theprocessor to access a cooperating merchant list comprising informationcorresponding to a plurality of merchants cooperating with a financialinstitution implementing the point of transaction e-receiptcommunication program; and for each of the plurality of cooperatingmerchants, request authorization from the customer for transaction dataassociated with any transactions performed by the customer at thecooperating merchant to be communicated to the financial institution forthe purpose of providing e-receipts to the customer.

In some embodiments, the customer's authorization for the customer to beenrolled in the point of transaction e-receipt communication program isreceived from an online banking session of the customer.

In some embodiments, the customer's authorization for the customer to beenrolled in the point of transaction e-receipt communication program isreceived from a mobile application session of the customer.

In some embodiments, the executable instructions further cause theprocessor to receive authorization from a plurality of enrollingmerchants for enrollment in the point of transaction e-receiptcommunication program; and build, based at least in part on theplurality of enrolling merchants, a cooperating merchant list comprisinginformation corresponding to a plurality of cooperating merchantscooperating with a financial institution implementing the point oftransaction e-receipt communication program.

In some embodiments, the executable instructions further cause theprocessor to receive customer identification information from themerchant; access a participating customer list comprising informationcorresponding to a plurality of customers participating in the point oftransaction e-receipt communication program; determine whether thereceived customer identification information corresponds to any of theplurality of customers in the participating customer list; if so,initiate communication of a confirmation message to the merchantindicating to the merchant that the customer is participating in thepoint of transaction e-receipt communication program; and wherein thetransaction data is received from the merchant in response to themerchant receiving the confirmation message.

In some embodiments, the executable instructions further cause theprocessor to receive customer identification information comprisingloyalty account information from the merchant; determining an identityof the customer based at least in part on the loyalty accountinformation received from the merchant; and wherein initiatingcommunication of the e-receipt to the customer is based at least in parton the determined identity of the customer.

In some embodiments, the transaction data corresponds to a cashtransaction performed by the customer with the merchant and wherein theexecutable instructions further cause the processor to receiveidentification information corresponding to an identity of the customer;associate the transaction data with the identity of the customer;generate the e-receipt based on the associated transaction data andidentity of the customer; and wherein initiating communication of thee-receipt to the customer is based at least in part on the determinedidentity of the customer.

In some embodiments, initiating communication of the e-receipt to thecustomer comprises initiating communication of the e-receipt to an emailaddress associated with the customer, to an online banking repositoryassociated with the customer and to a mobile application repositoryassociated with the customer.

In some embodiments, the executable instructions further cause theprocessor to receive, from an online banking session of the customer, arequest for an e-receipt associated with the at least one transaction;and wherein initiating communication of the e-receipt to the customer isin response to receiving the request.

In some embodiments, the executable instructions further cause theprocessor to receive, from a mobile application session of the customer,a request for an e-receipt associated with the at least one transaction;and wherein initiating communication of the e-receipt to the customer isin response to receiving the request.

According to an embodiment of the invention, a computer program productfor generating an e-receipt for an online banking transaction, thecomputer program product comprising a non-transitory computer readablestorage medium having computer readable program code embodied therewith,the computer readable program code comprising a computer readableprogram code configured to receive authorization from a customer for thecustomer to be enrolled in a point of transaction e-receiptcommunication program; receive transaction data corresponding to atleast one transaction performed by the customer at a point oftransaction of a merchant; and initiate communication, to the customer,of an e-receipt based at least in part on the received transaction data.

In some embodiments, the computer readable program code is furtherconfigured to request authorization from the customer for the customerto be enrolled in the point of transaction e-receipt communicationprogram.

In some embodiments, the transaction data is received as an e-receiptgenerated by the merchant and based on the at least one transactionperformed by the customer at the point of transaction of the merchant.

In some embodiments, the computer readable program code is furtherconfigured to access a cooperating merchant list comprising informationcorresponding to a plurality of merchants cooperating with a financialinstitution implementing the point of transaction e-receiptcommunication program; and for each of the plurality of cooperatingmerchants, request authorization from the customer for transaction dataassociated with any transactions performed by the customer at thecooperating merchant to be communicated to the financial institution forthe purpose of providing e-receipts to the customer.

In some embodiments, the customer's authorization for the customer to beenrolled in the point of transaction e-receipt communication program isreceived from an online banking session of the customer.

In some embodiments, the customer's authorization for the customer to beenrolled in the point of transaction e-receipt communication program isreceived from a mobile application session of the customer.

According to an embodiment of the invention, a method for providing ane-receipt to a customer includes receiving, at a processor of afinancial institution system, authorization from a customer for thecustomer to be enrolled in a point of transaction e-receiptcommunication program; receiving, at the processor of the financialinstitution system and from a merchant, transaction data correspondingto at least one transaction performed by the customer at a point oftransaction of a merchant; and initiating communication, by theprocessor of the financial institution system and to the customer, of ane-receipt based at least in part on the received transaction data.

Other aspects and features, as recited by the claims, will becomeapparent to those skilled in the art upon review of the followingnon-limited detailed description of the invention in conjunction withthe accompanying figures.

BRIEF DESCRIPTION OF THE DRAWINGS

Having thus described embodiments of the invention in general terms,reference will now be made to the accompanying drawings, which are notnecessarily drawn to scale, and wherein:

FIG. 1 is a diagram of an operating environment according to oneembodiment of the present invention for retrieval of electroniccommunications relating to customer purchase transactions, parsing ofdata within such electronic communications into structured data, andinclusion of such data into online banking;

FIG. 2 provides a high level process flow illustrating a method ofproviding an e-receipt for an online banking transaction, in accordancewith one embodiment of the present disclosure;

FIG. 3 is an exemplary embodiment of an e-receipt associated with themethod, in accordance with embodiments of the disclosure;

FIG. 4 is an exemplary embodiment of an account register associated withthe method, in accordance with embodiments of the disclosure;

FIG. 5 is a flowchart illustrating a method for providing e-receipts tocustomers, in accordance with embodiments of the disclosure;

FIG. 6 is a flowchart illustrating a method for providing e-receipts tocustomers, in accordance with embodiments of the disclosure using acooperating merchant list;

FIG. 7 is a flowchart illustrating a method for providing e-receipts tocustomers, in accordance with embodiments of the disclosure using aparticipating customer list; and

FIG. 8 is a flowchart illustrating a method for providing e-receipts tocustomers, in accordance with embodiments of the disclosure based oncustomer identity.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

Embodiments of the present disclosure now may be described more fullyhereinafter with reference to the accompanying drawings, in which some,but not all, embodiments of the disclosure are shown. Indeed, manydifferent forms may be possible and the disclosure should not beconstrued as limited to the embodiments set forth herein; rather, theseembodiments are provided so that this disclosure may satisfy applicablelegal requirements. Like numbers refer to like elements throughout.

Where possible, any terms expressed in the singular form herein aremeant to also include the plural form and vice versa, unless explicitlystated otherwise. Also, as used herein, the term “a” and/or “an” shallmean “one or more,” even though the phrase “one or more” is also usedherein. Furthermore, when it is said herein that something is “based on”something else, it may be based on one or more other things as well. Inother words, unless expressly indicated otherwise, as used herein “basedon” means “based at least in part on” or “based at least partially on.”It should also be understood that while some embodiments describe themethods or products as comprising one or more elements, the methods orelements may also consist of or consist essentially of the elementsdisclosed herein.

Furthermore, the term “product” or “account” as used herein may includeany financial product, service, or the like that may be provided to acustomer from an entity that subsequently requires payment. A productmay include an account, credit, loans, purchases, agreements, or thelike between an entity and a customer. The term “relationship” as usedherein may refer to any products, communications, correspondences,information, or the like associated with a customer that may be obtainedby an entity while working with a customer. Customer relationship datamay include, but is not limited to addresses associated with a customer,customer contact information, customer associate information, customerproducts, customer products in arrears, or other information associatedwith the customer's one or more accounts, loans, products, purchases,agreements, or contracts that a customer may have with the entity.

In the past few years, there has been an increase in the amount ofelectronic information provided by merchants to customers regardingpurchase of products and services. In the online purchase context,various electronic communications may be provided to the customer fromthe merchant relative to a purchase. For example, the merchant mayprovide the customer an electronic order confirmation communicationfollowing an online purchase. The order confirmation may be sent to thecustomer's computer and displayed in a web browser application. The webbrowser application typically allows the customer to print a hard copyof the order confirmation and to save the confirmation electronically.The merchant will also typically send an email containing the orderconfirmation to the customer's designated email account. The orderconfirmation is essentially an e-receipt for the online purchase. Theorder confirmation includes detailed information regarding the productsor services purchased. For example, in the case of a product, the orderconfirmation may include stock keeping unit “SKU” code level data, aswell as other parameters, such as order number, order date, productdescription, product name, product quantity, product price, productimage, hyperlink to the product image on merchant website, sales tax,shipping cost, order total, billing address, shipping company, shippingaddress, estimated shipping date, estimated delivery date, trackingnumber, and the like. The order confirmation also includes informationabout the merchant, such as name, address, phone number, web address,and the like. For most online transactions, the merchant will send atleast one second communication confirming shipment of the order. Theorder shipment confirmation is typically also sent via email to thecustomer and typically includes the same information as the orderconfirmation, and in addition, shipping date, tracking number, and otherrelevant information regarding the order and shipment parameters.

Many merchants now also provide e-receipts to customers shopping atbrick and mortar locations. In general, at the point of sale, thecustomer may have previously configured or may be asked at the time ofsale as to whether she wishes to receive an e-receipt. By selecting thisoption, the merchant will send an electronic communication in the formof an e-receipt to the customer's designated email address. Here again,the e-receipt will typically include a list of services and/or productspurchased with SKU level data, and other parameters, as well asinformation about the merchant, such as name, address, phone number,store number, web address, and the like.

Various merchants now also provide online customer accounts for repeatcustomers. These online customer accounts may include purchase historyinformation associated with the customer accessible by the customer viaID and passcode entry. Purchase history provides detailed informationabout services and products purchased by the customer includinginformation found on order confirmations and shipping confirmations foreach purchase. Online customer accounts are not limited to onlinepurchases. Many merchants also provide online customer accounts forcustomers that purchase services and products at brick and mortarlocations and then store these transactions in the customer's onlineaccount.

For the most part, order confirmations, shipping confirmations,e-receipts, and other electronic communications between merchants andcustomers are used only by the customer as proof of purchase and formonitoring receipt of purchased items (i.e., for archival purposes).However, there is significant data that can be gleaned from thiselectronic information for the benefit of the customer, so that thecustomer may have detailed information regarding purchase history,spending, and the like.

Another development in the past few years has been the growth of onlinebanking, whereby financial institution customers, (such as bank andcredit card customers), may view financial account transaction data,perform online payments and money transfers, view account balances, andthe like. Many current online banking applications are fairly robust andprovide customers with budgeting tools, financial calculators, and thelike to assist the customer to not only perform and view financialtransaction data, but also to manage finances. A current drawback withonline banking is that transactional level detail for a given purchaseby the customer is limited. Despite the large amount of information sentby merchants to customers regarding purchases, merchants currently donot provide purchase details to financial institutions. The onlyinformation provided to the financial institution is information aboutthe merchant and an overall transaction amount. For example, if afinancial institution customer purchases several clothing items from amerchant and uses a financial institution debit card, credit card orcheck, all that is provided to the financial institution is the merchantinformation and overall purchase. Product level detail that is presenton the receipt provided to the customer by the merchant is not providedto the financial institution.

The lack of detailed information regarding a given transaction in theonline banking environment limits a customer's ability to ascertain alarger picture of purchase history and financial transactioninformation. As a first example, if a customer makes several purchaseswithin a short time period with a particular merchant, all that thecustomer will see in online banking for each purchase is an overalldollar amount, the merchant name, and date of the purchase transaction.If the customer cannot recall what a particular purchase was for orwhether it was a legitimate transaction, the customer cannot viewdetails regarding the purchase via online banking to aid in the inquiry.Instead, the customer must locate and review receipts from the purchasesand match them by date and/or total purchase amount to online bankingdata to perform such analysis.

Lack of detailed purchase information also hinders use of otherfinancial tools available to the customer in online banking, such asbudget tools. In general, budget tools divide expenses into variouscategories, such as food, clothing, housing, transportation, and thelike. It is typically advantageous to provide such budget tools withonline banking information to populate these various categories withspend information. However, this is difficult where specifics regardinga purchase made by the merchant (such as SKU level data) are notprovided by the merchant to the financial institution for a givenfinancial transaction. As many stores provide a wide variety of servicesand products, such as in the case of a “big box” store that providesgroceries, clothing, house hold goods, automotive products, and evenfuel, it is not possible to dissect a particular purchase transaction bya customer at the merchant for budget category purposes. For thisreason, many current online budgeting tools may categorize purchases forbudgeting by merchant type, such as gas station purchases arecategorized under transportation and grocery store purchases arecategorized under food, despite that in reality, the purchase at the gasstation may have been for food or the purchase at the grocery storecould have been for fuel. Alternatively, some budget tools may allow acustomer to parse the total amount of a purchase transaction betweenbudget categories by manually allocating amounts from the purchasetransaction between each budget category. This requires added work bythe customer and may be inaccurate if the customer is not using thereceipt in making such allocations.

Customer cash purchases are also problematic for integration of customerpurchase transactions into online banking. In a cash transaction, thecustomer may initially withdraw cash from a financial account and thenuse the money for a purchase. In this instance, the customer's onlinebanking will have no information whatsoever regarding the purchasetransaction with a merchant, as there is no communication regarding thepurchase transaction between the financial institution and the merchant.For example, if the customer uses cash to purchase fuel at a gasstation, the financial institution has no way of determining that thepurchase transaction occurred and cannot use such information fornotifying customer of spending or budgeting regarding the fuel purchase.

As described above, currently financial institutions are not providedwith detailed transaction level information regarding a purchasetransaction by a customer from a merchant beyond merchant informationand overall transaction price for inclusion in online banking. Whiledetailed data (such as SKU level data) is provided to the customer viareceipts, such information is not provided by the merchant to thefinancial institution. The information is available to the customer butnot integratable into a customer's online banking for efficient andincreased beneficial use of the information. Currently, a customer mustretain her receipts and manually compare such receipts with onlinepurchase transaction data to obtain an understanding of the details of agiven purchase transaction.

In light of the above, the current invention contemplates use ofe-receipt data and other electronic communication data between amerchant and customer regarding a transaction in order to augmentpurchase transaction data in online banking. The general concept is toretrieve such electronic communications from the customer, parse thedata in these electronic communications, and associate the data from theelectronic communications with the corresponding online purchasetransaction data.

An initial barrier to integration of electronic communication datareceived by a customer from a merchant regarding a purchase transactionfor inclusion into online banking is data format. Online banking data isin a structured form. Financial institutions currently use a datastructure conforming to Open Financial Exchange “OFX” specifications forthe electronic exchange of financial data between financialinstitutions, businesses and customers via the Internet. E-receipts,such as electronic order confirmations, shipment confirmation, receipts,and the like typically do not comply to a uniform structure and aregenerally considered to include data in an “unstructured” format. Forexample, while one merchant may provide data in an electroniccommunication to a customer in one format, another merchant may use acompletely different format. One merchant may include merchant data atthe top of a receipt and another merchant may include such data at thebottom of a receipt. One merchant may list the purchase price for anitem on the same line as the description of the item and list the SKUnumber on the next line, while another merchant may list the data in acompletely opposite order. As such, prior to integration of electroniccommunications relating to customer purchases into online banking, thedata from such electronic communications must be parsed into astructured form.

FIG. 1 is a diagram of an operating environment 10 according to oneembodiment of the present disclosure relating to determining parametersfor online banking transactions, parsing of data within such onlinebanking transactions into structured data, and generation of e-receiptsthat may be used by the customer. As illustrated a customer maintainsone or more computing devices 12, such as a PC, laptop, mobile phone,tablet, television, or the like that is network enabled forcommunicating across a network 14, such as the Internet, wide areanetwork, local area network, Bluetooth network, near field network, orany other form of contact or contactless network. Also, one or morenetwork-enabled online banking systems 26 and merchant computing systems16 may be in the operating environment.

The online banking system 26 is configured to initiate and/or processonline banking transactions such as transactions between banks or otherfinancial institutions, transactions between accounts within a financialinstitution, or the like. For example, the system may be configured toinitiate and/or process online banking transactions such as transferrequests, transfer confirmations, online bill pay requests, online billpay confirmations, retirement account contributions or withdrawals,purchase and/or redemption of equities such as stocks, bonds, orcertificates of deposit, or the like. While transfers such as EFTtransfers, online transfers, P2P transfers, or others will primarily bediscussed, it should be understood that other types of online bankingtransactions may be initiated and/or processed, e.g., an e-receiptgenerated, using the system as disclosed herein.

In general, the online banking computing system will monitor actions ofa customer on an online portal such as a financial institution website,email account, customer accounts page, or mobile device application.When the system determines that an online banking transaction hasoccurred, the system may automatically or on request generate astructured e-receipt to provide information, records, and convenience tothe customer. In some embodiments, the system evaluates unstructurede-receipts that have been generated by financial institutions, such asin comma delimited, text, or OFX format, in order to extract data fromthe e-receipts. The system may be linked to one or more financialinstitutions via the network 14. In an embodiment, the online bankingcomputing system 26 connects to a financial institution server, such asthe merchant computing system 16. In the context of a transfer betweentwo financial institutions, the system may connect to multiple merchantcomputing systems 16 in order to receive data and/or metadata associatedwith the online banking transaction from both the transferor and therecipient.

In the context of an online purchase experience, the merchant computingsystem 16 may be one or more financial transaction servers that, eitherindividually or working in concert, are capable of providing web pagesto a customer via the network 14, receiving purchase orders forproducts, such as stocks or bonds, selected by the customer,communicating with the customer and third party financial institutionsto secure payment for the order, and transmitting order confirmation,and possibly confirmation information, to the customer via the network14 regarding the transaction. In the context of an on-line purchase, themerchant computing system 16 may include a software product for scanningor receiving information about products or services being purchased bythe customer and communicating with the customer and third partyfinancial institutions to secure payment for the order. Either thecustomer computing device or a connected merchant server may be used tocommunicate order confirmation or purchase confirmation information tothe customer related to the purchase transaction. If the customer has anonline account with the merchant, the merchant computing system may alsolog the transaction information into the customer's online account.

In some embodiments, the merchant computing system will provide thecustomer with information relating to the transaction. In the context ofan online purchase, the communications may take the form of purchaseorder confirmations provided as a web page or as an email or as both. Insome embodiments, the merchant computing system may provide a web pagepurchase order confirmation and advise the customer to either print,electronically save, or book mark the confirmation web page. The orderconfirmation includes detailed information regarding the products orservices purchased, such as for example, in the case of a product,equity name, price per share, asset allocation category, an analysis ofthe customer's asset allocation, historical price data for the equity,appreciation, SKU code level data, as well as other parametersassociated with the product, such as type/category, size, color, and thelike, as well purchase price information, information associated withthe merchant, and the like. The merchant computing system may also sendother subsequent communications, such as communications confirmingcompletion of the order, which typically includes the same informationas the purchase order confirmation, and in addition, completion date,tracking number, and other relevant information regarding the order. Inthe context of an in-store purchase, the merchant computing system maysend an e-receipt comprising information similar to that of the purchaseorder confirmation. In some instances, the customer may actually receivea paper receipt, which the customer may choose to scan into anelectronic form and save in a storage device associated with thecustomer computing device 12.

For a plurality of different transactions, a customer may include onlinebanking transaction related data (e.g., transfer confirmations, transferrequests, online bill pay, scanned receipts, typed or handwritten notes,invoices, bills of sale, and the like) in various locations and invarious forms. The transfer related data could be stored in a storagedevice associated with the customer computing device 12, or in an emailserver 18, or in a customer's account at the online banking computingsystem 26. Furthermore, as mentioned, in some embodiments at least apart of the online banking transaction related information is in anunstructured format. Each financial institution may use a customizedreporting format for the online banking transactions, whereby variousdata relating to the transaction may be placed in different sequences,different locations, different formats, and the like for a givenfinancial institution. Indeed, a given financial institution may evenuse different data formatting and structuring for differentcommunications with the customer (e.g., transfer confirmation, transferrequest, online bill pay, equity purchase via a broker, online customeraccount information, and the like).

In some embodiments, the financial institution may aggregate transactiondata from a variety of sources in addition to receiving transaction datadirectly from merchants. To aggregate and structure data related toonline banking transactions, the operating environment further comprisesan aggregation computing system 20. The aggregation computing system isoperatively connected to at least one of the customer computing device12, the merchant computing system 16, the online banking computingsystem 26, and the email server 18 via the network 14. The aggregationcomputing system is configured to initially search and locate electroniccommunications associated with online banking transactions made by thecustomer, in for example, the customer's email, computer storage device,online accounts, and the like. For this purpose, the system mayoptionally include an authentication/authorization computing system 22that comprises security IDs and passwords and other security informationassociated with the customer for accessing customer's email, storagedevices, and customer online accounts.

Regarding online banking transaction parameter extraction, aggregationcomputing system 20 initially gains access to the customer's onlinebanking accounts, email accounts, and the like and retrieves metadatasuch as message bodies and headers comprising data fields related to theonline banking transaction, such as recipient, amount, date/time sent,notes, and the like. In some embodiments, the aggregation computingsystem accesses the metadata directly. In other embodiments, theaggregation computing system may run search queries of the customer'semail account or financial institution database based on knowntransaction types and/or phrases associated with online bankingtransactions, such as “receipt,” “transfer confirmation,” “transferrequest,” or the like. In some embodiments, the aggregation computingsystem 20 gains access to a customer's email or accounts information inorder to review e-receipts that are generated by financial institutionsor other parties related to the online banking transaction. The email oraccounts information may also include metadata or keywords that areextracted by the system. Once the keywords metadata are extracted,further filtering may occur to locate relevant online bankingtransactions. Examples of further filtering may be searches based onknown online financial institutions, third parties known to conductonline transactions with the customer, text in the metadata thatcorresponds to known online banking transaction text, such as the text“transfer,” “order,” “ordered,” “request,” “payment,” “bill,” “invoice,”“confirmed,” “confirmation,” “notification,” “receipt,” “e-receipt,”“ereceipt,” “return,” “pre-order,” “pre-ordered,” “tracking,” “on itsway,” “received,” “fulfilled,” “successful,” and the like.

Based on the email, online account, and/or metadata analysis, the dataassociated with the online banking transaction may then be accessed. Theretrieved data for the online banking transactions are parsed to extractthe transaction information and/or parameters contained therein. Suchparsing operation can occur in a variety of known ways. However, becausethe text contained in online banking transactions is unstructured (asopposed to the structured tagged elements in a hypertext markup language(HTML) web page which delineate and make recognizable the various fieldsor elements of the web page), in one embodiment predefined templates areused that have been specifically created to identify the variousindividual elements or entities of interest in a given online bankingtransaction from a financial institution. Use of these predefinedtemplates to parse a retrieved online banking transaction occurs withinaggregation computing system 20. Because it is known from headerinformation which financial institution is associated with the onlinebanking transaction of interest, a template specific to the financialinstitution may be used.

The above describes parsing of online transaction confirmations, onlinetransaction requests, or e-receipt data. As mentioned, a customer mayscan and save paper receipts, typed or printed notes, invoices, bills ofsale, and the like in a storage device or print and save purchase orderand transfer confirmation communications sent to the customer by themerchant via a web page. In this instance, the aggregation computingsystem 20 may first perform optical character recognition “OCR” on thescanned or printed receipts prior to performing the processing performedabove. Further, a customer may maintain an online account with afinancial institution containing transfer data information. In thisinstance, the aggregation computing system 20 will access the dataonline via communication with the online banking computing system toretrieve this data. The aggregation computing system 20 may use columnand/or row headers associated with the online data to parse the data, orit may use procedures similar to the above and discussed below to parsethe data into appropriate fields.

Returning to data processing procedures, in some embodiments,context-free grammars “CFGs” are used to parse fields from purchasetransaction data. In some embodiments, instead of using grammars forparsing natural language (e.g., English) structures, the system may usedefined smaller grammars describing a particular message format, forexample: “(Successful transfer)(Details about transfer)(Date oftransfer)(Remaining balance calculation),” and the like. Further, theCFGs may be individually defined, such as in a Backus-Naur Form (BNF)format, or templates may be used for data extraction. In instances wheretemplates are used, these created templates are grammar and can beconverted by known tools, such as Another Tool for Language Recognition“ANTLR”, into mail-specific grammars or e-receipt-specific grammars oronline customer account information-specific grammars. ANTLR is thenused again to convert these grammars into extraction parsers, which canbe used by the aggregation computing system 20 to parse the messagebodies, metadata, online data, or the like, to extract the entities ofinterest from them. Examples of such extracted entities includerecipient name, recipient account number, transferor name, transferoraccount number, amount, remaining balance, memo, date, productpurchased, payment made, order number, order date, product description,product name, product quantity, product price, product image, hyperlinkto the product information on broker website, order total, billingaddress, confirmation number, and the like.

Other extraction parsers may be used, such as regular expressionextraction, which can be used as a brute force pattern matching approachacross the information record. With this technique, each word in a givenorder record is matched against a set of rules. If the rules are met,the piece of text matching the set of rules is returned. For example,shipping companies frequently use a 21 digit tracking number beginningwith “1Z” or “91.” The aggregation computing system may scan an entirepurchase information record to find a 21 digit number with “1Z” or “91”as the first 2 digits. The matched text can then be extracted and usedto determine shipping information.

In another embodiment, an HTML document object model (DOM) approach maybe used to parse data records. For example, the metadata associated withan online transfer between accounts at different financial institutionmay include the institution tags. The aggregation computing system mayuse these tags to identify the institution names and/or accounts. Oncerelevant information is extracted from online banking transaction, theinformation is stored in data records in a structured database 24.

As is understood, once the transaction data has been extracted, variousinformation regarding a particular transaction is now known, such astransferor, transferee, amount, remaining balance, online payment,account number, merchant name, merchant web address, transfer number,transfer date, transfer description, and the like. This data can befurther enriched with additional and/or updated information associatedwith products or services within the data. For example, the data may beenriched with transfer information and the like from an online bankingcomputing system 26. In particular, the aggregation computing system may(1) communicate with the merchant computing system 16 and/or onlinebanking computing system 26 to generate e-receipts for online bankingtransactions within or between financial institutions or other parties,(2) may determine supplemental information associated with the onlinebanking transaction, and/or (3) communicate with the customer regardingimprovements or options available to the customer associated with theonline banking transaction.

The above is a description of a computing system according to oneembodiment of the present invention. An example of an aggregationcomputing system is described in U.S. Published Patent Application No.2013/0024525 titled Augmented Aggregation of Emailed Product Order andShipping Information, the contents of which are incorporated herein byreference.

Turning now to FIG. 2, a high-level flow chart of a system and methodfor generating an e-receipt for an online banking transaction isprovided. In some embodiments, the system includes a computer apparatusincluding a processor and a memory; and a software module stored in thememory, comprising executable instructions that when executed by theprocessor cause the processor to: receive an unstructured e-receipt froma financial institution (or other entity such as a merchant), theunstructured e-receipt comprising parameters of an online bankingtransaction; identify unstructured data associated with the parameters;convert the unstructured data into structured data; and generate ane-receipt for the online banking transaction using at least thestructured data.

In block 202, in some embodiments the system receives an unstructurede-receipt from a financial institution, the unstructured e-receiptcomprising parameters of an online banking transaction. An unstructurede-receipt is a communication from or by a financial institution thatincludes data in a format that is not native or accessible to thesystem. For example, an unstructured e-receipt may be an email from afinancial institution acknowledging that a transfer request hascompleted. The email includes textual information, such as the amount ofthe transaction and the recipient account of the transaction, but thetextual information is not labeled in a structured manner. In otherwords, the email may include text describing the online bankingtransaction, but the text is not readily transferrable from one formatto another or labeled with the subject matter of the text. In someembodiments, the unstructured e-receipt is a confirmation page on awebsite, such as the confirmation page received after requesting anonline transfer. Again, the confirmation page may include textualinformation and may also include metadata in the html code encoding forthe page that describes information about the online bankingtransaction, but the textual information and the metadata are notaccessible or usable by the system without further manipulation. Anytype of communication from a financial institution may be considered anunstructured e-receipt.

In an embodiment, the unstructured e-receipt includes parameters of theonline banking transaction. Parameters define the characteristics of theonline banking transaction. For example, the parameters of the onlinebanking transaction may include the amounts associated with the onlinebanking transaction, the parties associated with the online bankingtransaction, the data and time associated with the online bankingtransaction, status of the accounts after completion of the onlinebanking transaction, products associated with the online bankingtransaction (e.g., equities purchased), any memos or notes associatedwith the online banking transaction, and the like. As should beunderstood, online banking transactions may have various parameters andthose parameters may change over time. For example, the advent of mobiledevices has led to an increase in online banking transactionsfacilitated through mobile device apps (e.g., P2P transfers). The systemmay also therefore determine parameters associated with online bankingtransactions associated with mobile devices, such as the deviceidentifier, the channel, the application, and the like.

In some embodiments, the system determines the parameters by evaluatinga list provided by one or more financial institutions, such as therecipient financial institution and the transferor financialinstitution. The list may be a default list of online bankingtransaction parameters. In a further embodiment, the parameters areselected or input by the customer so that the parameters of thetransaction are customized by the customer.

As used herein, an online banking transaction means a transaction thatcompletes at least some part of the transaction via an online channel. Atransaction may be any interaction between one party or account and atleast one more party or account. In an exemplary embodiment, atransaction is an online banking transaction such as a transfer of fundsbetween accounts. In some embodiments, the online banking transaction iscompleted only via online channels such that a paper trail is notcreated. In further embodiments, the online banking transaction iscompleted primarily through online channels such that the only steps oractivities that do not occur via the online channel are non-material tothe online banking transaction.

In block 204, the system identifies unstructured data associated withthe parameters. In an embodiment, unstructured data are data that do notcomply to a uniform structure. For example, a first financialinstitution may include data for an online banking transaction in afirst format and a second financial institution may use a completelydifferent format for providing information to the customer. In someembodiments, a financial institution will use different formats fordifferent types of communication to a customer. For example, a transferconfirmation acknowledging a transaction may have a first format while atransfer request acknowledging initiation of the transfer may have asecond format.

In some embodiments, the unstructured data includes metadata provided byone of the parties associated with the transaction. The metadata is datathat are obscure, in a proprietary format, or hidden from view relativeto the primary elements of the communication on the transaction. Forexample, a webpage may display a confirmation receipt for a transferrequest. The code behind the webpage, e.g., the html code, may includemetadata related to the destination of the transfer request, the accountnumber of the transferring accounts, or the like. In an embodiment, themetadata are not accessible by the customer but is available to acomputerized system such as disclosed herein.

In further embodiments, the unstructured data are extracted data fromcommunications from financial institutions. For example, textual datamay be extracted using optical character recognition (OCR) technologyand/or software. Predictive technologies may also be used to extractinformation from a diverse set of communications from financialinstitutions. Metadata may be extracted using html readers and/or OCRtechnology. In an embodiment, the unstructured data are extracted usinga combination of translational and recognition software that bothtranslates the format of the communication (e.g., binary orcomma-delimited) and recognizes the structure inherent in the translatedcommunication (e.g., recognizes that the translated word “amount”identifies a parameter of the transaction labeled as the amount).

In an embodiment, the metadata and extracted data include informationrelated to the parameters of the online banking transaction. Themetadata may include amount data, party data, memo data, category data,timing data, and product level data. Product level data is informationon the products and/or services associated with a transaction. Productlevel data may include the name of the product, a category for theproduct, a code associated with the product (e.g., an asset allocationcode, a serial number, or the like), and/or required information for theproduct (e.g., disclosures relating to equities). The metadata separatesthe transaction from a single non-informational record at the financialinstitution into a data-rich set that the financial institution, thecustomer, and/or third parties may use. In some embodiments, themetadata is used to provide appropriate or desirable offers tocustomers.

In some embodiment, the unstructured data also include transaction leveldata, such as the date of the transaction, the total amount of thetransaction, the location of the transaction, the merchant associatedwith the transaction (e.g., broker), the category of the merchant, anycontact information for the merchant, and the like. In this embodiment,purchase and or sale of equities such as stocks, bonds, mutual funds,and certificates of deposit are primarily considered, although othertypes of purchases such as insurance policies and the like may also beincluded. The transaction level data may be present in the metadataand/or in extracted data. For example, the metadata may include theamount of a transfer and the unstructured e-receipt generated by thefinancial institution may also include a textual depiction of the amountof the transfer.

In some embodiments, the system receives unstructured data from acustomer account. In an embodiment, the system receives the unstructureddata via a network, such as a wired or wireless network. In an exemplaryembodiment, the unstructured data is received via the Internet. Forexample, the unstructured data may be received via the system accessinga customer's account on an external website, e.g. an email account, anonline bill pay account, an online banking account, or the like. In oneexample, the customer provides the customer's log-in credentials, e.g.,username and password, and the system logs into the customer's accountto access online banking transaction comprising the unstructured data.In an embodiment, the system logs into the customer's account with thecustomer's permission and scans the account for unstructured data thatmay be associated with transaction data. For example, the system mayidentify a transfer request from a financial institution. The system mayalso log into a history of the customer's transactions at anotherfinancial institution to access unstructured data.

In another embodiment, the customer provides the unstructured data tothe system. For example, the customer may forward the transferconfirmation to an email account associated with the system. In oneembodiment, the email account associated with the system is unique tothe customer. In a further embodiment, the email account is an accountthat receives unstructured data from more than one customer. Forexample, a generic account may be set up to receive unstructured datafrom multiple customers. The system evaluates the unstructured data forboth transaction-associated information as well as customer-identifyinginformation.

In some embodiments, the system receives the unstructured data on aregular basis. For example, the system may automatically log into acustomer account on a regular basis to determine online bankingtransaction data. In another embodiment, the system receives theunstructured data after being triggered by the customer. For example,the customer may request an update of unstructured data related toonline banking transactions. In another example, the customer completesan online banking transaction via the customer's financial institutionand the withdrawal or deposit from the customer's financial account isthe trigger that causes the system to receive the unstructured data. Thesystem may determine that an online banking transaction has occurred,determine parameters associated with the online banking transaction, andreceive the unstructured data regarding the transaction.

In an embodiment, the customer account is the history of the customer'stransactions and other actions with a third party entity, such asanother financial institution. For example, some financial institutionskeep records of transactions conducted by customers at the financialinstitution. The customer may be able to access these records, such asby entering a username and password, in order to view a record of thetransactions conducted by the customer. In many financial institutions,the records include the parameters associated with the online bankingtransaction.

In some embodiments, the system determines a format of the unstructureddata. The format of the unstructured data is the layout and structure ofthe communication that embeds the unstructured data. For example, atransfer receipt from a first financial institution may have metadata ofa certain format. A second financial institution, however, may havemetadata on the transfer in a different format. The system determinesthe information by evaluating the images in the metadata in the transferreceipt or request and extracting information from the metadata. Forexample, the system may evaluate hypertext markup language code in thetransfer receipt to determine generic codes that a financial institutionuses for different types of information. In a further embodiment, thesystem provider receives information on format of unstructured data fromother financial institutions, stores that information in a database, andevaluates metadata from the financial institution by cross-referencingthe database.

In an embodiment, the system retains a copy of the format used by afinancial institution. For example, many financial institutions use thesame format for their online banking transactions with differentcustomers. While the content of the online banking transaction maychange, e.g., the amount and destination of the transfer, the format ofthe online banking transaction remains the same. By saving this format,the system increases the speed with which the system can identify theunstructured data. In an embodiment, the system determines a diagnosticfeature of the online banking transaction, such as a financialinstitution name, and then determines a format for the online bankingtransaction from a database.

In block 206, the system converts the unstructured data into structureddata. In some embodiments, the conversion is based on the format of theonline banking communication. Once the system has determined the formatof the online banking transaction, the system is able to convert theunstructured data in the communication into structured data that thesystem may use for many different purposes. For example, the system maydetermine that transfer request is from a first financial institutionusing a specific format. The system uses the known format to determinewhat information in the transfer request to include in the e-receipt,e.g., determines which information in the transfer request should beused to populate fields in the e-receipt. For example, the system mayidentify the transferor from the metadata in the transfer request anddetermine that the name of the financial institution.

In block 208, the system generates a structured e-receipt for the onlinebanking transaction using at least the structured data. In anembodiment, a default format for a structured e-receipt is used. Thedefault format may be particular to a specific type of online bankingtransaction. In other words, a default format for a transfer may bedifferent from a default format for an online bill pay. In anotherembodiment, the format of the structured e-receipt is customized by thecustomer, who may select which fields to include in the structurede-receipt. In an embodiment, the system provides a graphical userinterface that allows a customer to drag and drop or otherwise inputfields into an e-receipt model in order to construct a desiredstructured e-receipt. As the unstructured data associated with theonline banking transaction has been converted into structured data, thesystem has identified elements of the online banking transaction thatcorrespond to parameters and can input those elements into thestructured e-receipt. The structured data is data that shares a commonformat accessible to the system. As should be understood, the structureddata may be stored in a database associated with the system.

In block 210, the system determines a transaction at a financialinstitution corresponding to the structured e-receipt. In someembodiments, because the transaction is an online banking transaction,the system matches the structured e-receipt to the transaction in theonline banking transaction history. In this manner, the system is ableto compare the structured e-receipt from the transaction to dataassociated with transactions at a financial institution, which are alsoin a structure accessible to the system. It should be understood thatthe structured e-receipt and the transaction in the transaction historydo not necessarily have every parameter be the same. For example, thedate that a transfer request initiated from a first financialinstitution may differ from the date that the transfer request completedat a second financial institution. The system matches the online bankingtransaction structured e-receipt to the online banking transaction inthe transaction history within a level of error that allows for minordeviations in the details of the transaction.

In block 212, in some embodiments the system associates the structurede-receipt with the transaction at the financial institution. Byassociating the structured e-receipt with the transaction, the systemmakes the structured e-receipt available to the customer. For example,the customer may go to the customer's account register and be able toselect a link to view the structured e-receipt associated with the lineitem transaction. The association may also facilitate sharing and/orcategorizing of the structured e-receipt or transaction.

In block 214, in some embodiment the system provides the structurede-receipt to the customer or a third party on behalf of the customer.The structured e-receipt may be provided in an electronic format or in ahard copy. In an embodiment, the structured e-receipt may be downloaded,emailed, or otherwise communicated to the customer or to a third partyat the request of the customer. In some embodiments, the structurede-receipt maintains the structured data format within the structurede-receipt so that the data in the structured e-receipt may be extractedand used with software that recognizes the structured data. For example,the customer may push a structured e-receipt of an equity purchase to atax planner to assist the tax planner with completing the customer'staxes. The tax planner may have software that extracts the structureddata from the structured e-receipt and thereby receive the parameters ofthe online banking transaction, which otherwise may be difficult todetermine.

In a further example, the structured e-receipt is provided to afinancial institution as evidence of transaction history when qualifyingfor a loan. For example, when qualifying for a mortgage often the lenderrequires information on all transfers into and/or out of the customer'saccounts. By providing structured e-receipts to the lender, including insome embodiments e-receipts with structured data, the customer may easethe process of qualifying for a loan by providing comprehensive data ontransfers to the lender.

Turning now to FIG. 3, an exemplary embodiment of a structured e-receiptassociated with the method is provided. In this example, the structurede-receipt 300 is an e-receipt for an online banking transfer between twoaccounts that is generated by the system. As discussed, the systemgenerates the structured e-receipt based on at least some of theunstructured data that has been converted to structured data. Theunstructured data may be extracted from metadata or extracted dataassociated with the online banking transaction. In some embodiments, thestructured e-receipt includes various types of information including:(a) financial institution information; (b) transaction information; and(c) supplementary information. While this example includes at least someof each type of information, it should be understood that the structurede-receipt does not necessarily require each type of information. Forexample, the supplemental information may be missing but the system andmethod may still be able to generate a structured e-receipt includingfinancial institution information and transaction information.

The financial institution information may include the financialinstitution name 302, as shown. In further embodiments, additionalfinancial institution information is included in the e-receipt, such ascontact information, address, institution type or category, internetinformation for the financial institution such as web address, and thelike. The financial institution information can be used to assist indetermining the format of the unstructured data within the metadata. Forexample, the system may determine the financial institution's name,cross-reference the name with a format stored in the database, and usethe stored format to generate the e-receipt.

The transaction information may also be included in the e-receipt. Insome embodiments, a summary of the online banking transaction isprovided in the receipt. The summary may include the amount of thetransaction, the recipient, and the date of the transaction. In someembodiments, the e-receipt also includes fields for the amount of thetransaction 304, the date of the transaction 306, the recipient of thetransaction 308 (e.g., the transferee), the remaining balance in theaccount after the transaction 310, any memos provided by one or moreparties to the transaction 312, the frequency of occurrence of thetransaction 314, and the like. In further embodiments, the transactioninformation may include the transaction time, the transaction location,the channel for payment of products associated with the transaction(e.g., EFT transfer, online bill pay, wireless P2P transfer, or thelike), or other information associated with the transaction generally.

The supplementary information may include analysis of the online bankingtransaction and suggestions or offers from the merchant based on theanalysis 316. For example, the system may compare details of thee-receipt to previous actions and/or transactions by the customer. Inone embodiment, the system matches the details to the e-receipt, such asthe amount and the recipient, to different transactions by the user inorder to find matching or similar transactions. In an exemplaryembodiment, as shown, the system is able to identify recurringtransactions and suggest implementing an automatic online bankingtransaction to provide convenience to the customer. In some embodiments,the comparison between the online banking transaction that is thesubject of the e-receipt and earlier transactions is based on astatistical analysis of the similarities between the e-receipt and othertransactions or e-receipts.

The system may determine the corresponding transactions by comparingelements of the structured data and the previous transaction data. Forexample, the amount, the date, the financial institution, and/or thelocation may be used to determine a corresponding transaction. In someembodiments, the system determines corresponding transactions within acertain confidence level, such as by determining a likelihood that thestructured data and the transaction would share selected elements atrandom. When the likelihood is very small e.g., below a predeterminedthreshold, that the similarities between the structured data and thetransaction would occur at random, the system determines that thestructured data corresponds to the transaction.

In a further embodiment, the system also assists the customer incategorizing online banking transactions based on the e-receipt. Forexample, the system may prompt and/or suggest the customer to categorizethe e-receipt. In some embodiments, the system analyzes components ofthe e-receipt to suggest a category. For example, the system may analyzethe memo field, the recipient field, the date field, or a combination ofthe fields to determine a likely, based on statistical analysis,e.g., >95% confidence, that the online banking transaction is associatedwith a specific category such as rent, mortgage, credit card payment,retirement account investment, equity purchase, or the like. The systemcoordinates with online budgeting software to assist the customer inmanaging categorization of online banking transactions.

In FIG. 4, an exemplary screenshot of an account register at a financialinstitution is provided, in accordance with an embodiment of theinvention. The account register 400 may include various informationpages, such as pages on accounts 402, transfers 404, and customerservice 406. In some embodiments, the accounts pages include informationon transactions in various accounts, e.g., checking, credit card,savings, investment, and the like. In some embodiments, the transferspage 404 includes information on online banking transactions such astransfers, online bill pays, equity purchases, and the like. Forexample, the transfers page 404 may include the date 408 that atransaction occurred or cleared, a description of the transaction 410,the amount of the transaction 412, and the balance 414 of the accountafter the transaction clears.

The date of the transaction may be the actual date that the transactionoccurred, the date that the financial institution received notice of thetransaction, an indication that the transaction is still in processing,or some other date associated with the transaction. For example, atransfer request may occur on the date that it is received. In contrast,an online bill pay request may occur on a first day and the confirmationof the receipt may clear on a second day.

As discussed the description in the transaction register is typicallyvery general. In some embodiments, the transaction register is updatedwith information based on the system. For example, the customer mayselect 416 a transaction, e.g., select a radio button or the like, andinformation or offers 418 determined by the system may be presented tothe customer in the transfer page 404. In some embodiments, offers arealso provided to the customer. For example, links to offers may bepresented on the transfer page, pop-up windows may present offers, orthe like.

As discussed, financial institution do not receive detailed informationon transactions from financial institutions. Instead, as shown, thetransfer page discloses high-level information such as the channel bywhich the transaction occurred. For example, the channel may include atransfer, an online bill pay, a credit or the like.

According to various embodiments of the invention, a financialinstitution may accept enrollment from customers and/or merchants into apoint of transaction e-receipt communication program whereby enrolledmerchants communicate transaction data and/or e-receipts to thefinancial institution for aggregation and communication of e-receipts tothe enrolled customers. The financial institution can then providee-receipts to the customer over a variety of channels such as overemail, online banking, mobile application or otherwise withoutnecessarily needing access to a customer's email inbox for gatheringtransaction data. Of course, in some cases, the financial institutionmay also gain access to the customer's email inbox or other sources ofdata to supplement the transaction data received from merchants enrolledin the program.

In various embodiments, a customer may be invited to enroll in theprogram at the point of sale or point of transaction (POT). The POT maypresent the customer, during or after the transaction, an invitation toenroll in the program. The merchant, for example, may present a messageto the customer at the POT describing the program and inviting thecustomer to participate. In some cases, the customer of the merchant maynot be a customer of the financial institution administering theprogram, in which case, the customer may become a customer of thefinancial institution or only enroll in the program by providingsufficient personal information for the financial institution todetermine the customer's identity and associate it with transaction datafrom merchant transactions.

One benefit of the program is to centralize aggregation andcommunication of e-receipts for customer and prospective customer sothat the customers may get a comprehensive view of their e-receipts froman online banking or mobile application.

Referring now to FIG. 5, a flowchart illustrates a method 500 forproviding e-receipts to customers. The first step, represented by block502, is to receive authorization from a customer for the customer to beenrolled in a point of transaction e-receipt communication program. Thenext step, represented by block 504, is to receive transaction datacorresponding to at least one transaction performed by the customer at apoint of transaction of a merchant. The final step, represented by block506, is to initiate communication, to the customer, of an e-receiptbased at least in part on the received transaction data.

Referring now to FIG. 6, a flowchart illustrates a method 600 forproviding e-receipts to customers using a cooperating merchant list. Thefirst step, represented by 602, is to access a cooperating merchant listincluding information corresponding to a plurality of merchantscooperating with a financial institution implementing the point oftransaction e-receipt communication program. The next step, representedby block 604, is for each of the plurality of cooperating merchants,request authorization from the customer for transaction data associatedwith any transactions performed by the customer at the cooperatingmerchant to be communicated to the financial institution for the purposeof providing e-receipts to the customer. The next step, represented byblock 606, is to receive authorization from a plurality of enrollingmerchants for enrollment in the point of transaction e-receiptcommunication program. The final step, which may be performed earlierthan some or all the other steps discussed with reference to FIG. 6, isto build, based on the enrolling merchants, the cooperating merchantlist including information corresponding to the cooperating merchants.

Referring to FIG. 7, a flowchart illustrates a method 700 for providinge-receipts to customer using a participating customer list. The firststep, represented by block 702, is to receive customer identificationinformation from the merchant. Next, represented by block 704, is toaccess a participating customer list including information correspondingto a plurality of customers participating in the point of transactione-receipt communication program. Next, as represented by block 706, isto determine whether the received customer identification informationcorresponding to any of the plurality of customers in the participatingcustomer list. Finally, as represented by block 708, the next step isto, if the customer identification information corresponds to any of thecustomers in the list, initiate communication of a confirmation messageto the merchant indicating to the merchant that the customer isparticipating in the point of transaction e-receipt communicationprogram.

Referring now to FIG. 8, a flowchart illustrates a method 800 forproviding e-receipts to customers based on customer identity. The firststep, represented by block 802, is to receive customer identificationinformation. For example, a loyalty card, membership card or the likemay provide customer identification information to the merchant, whichcommunicates the customer identification information to the financialinstitution. The next step, represented by block 804, is to determine anidentity of the customer based on the received customer identificationinformation. The next step, represented by block 806, is to associatereceived transaction data with the identity of the customer. The finalstep, as represented by block 808, is to generate an e-receipt based onthe associated transaction data and identity of the customer.

One or more of the steps of FIGS. 5, 6, 7 and/or 8 may be performed by afinancial institution system or server. Further, as discussed elsewhere,one or more of the steps may be performed by an acquiring bank system orserver and/or a merchant bank system or server.

In various embodiments, the e-receipt is formatted in a format specifiedby the merchant. In some cases, the merchant accesses the program inorder to confirm the identity of the customer and/or to confirm that thecustomer is enrolled in the program and the merchant communicates thee-receipt to the customer instead of the financial institutioncommunicating the e-receipt to the customer. In some cases, thefinancial institution provides confirmation to the merchant that thecustomer is enrolled in the program and the merchant communicates thee-receipt to the customer directly. In some embodiments, the merchantcommunicates the e-receipt to the financial institution concurrently andthe financial institution can then store and aggregate e-receipts forthe customers enrolled in the program.

In some embodiments, the merchant enrolled in the program is given anoption to choose its own e-receipt design (whether communicated to thecustomer directly from the merchant and/or from the financialinstitution) or to choose a standardized e-receipt design and/orfinancial institution e-receipt design.

In some embodiments a point of transaction or point of sale network ofone or more merchants is connected with the financial institution forcommunicating transaction data and customer identification informationto the financial institution for use by the systems disclosed herein. Insome instances, more than one network of merchants and/or merchantscommunicates data to the financial institution and/or some other systemfor aggregation of the data and use in the program for providinge-receipts to customers.

In various embodiments, a third party that administers a point oftransaction or point of sale system at one or more merchant locationsand/or administers a point of transaction or point of sale network mayaggregate transaction and customer identification information for use inthe methods disclosed herein. For example, a third party may administera point of sale network for a regional grocery store having multiplelocations spread across a region. This third party may aggregateinformation from its POS network and communicate it to a serveradministered by the financial institution administering the program inorder for the server to determine whether the identification informationmatches a customer participating in the program. If so, the financialinstitution may communicate one or more e-receipts to the customer basedon the customer's preferences. Furthermore, there may be multiple pointof sale networks that communicate transaction and customeridentification data to one or more financial institution systems for useby embodiments of the invention to communicate e-receipts to customers.

In some embodiments, a payment clearinghouse and/or an acquiring bank ormerchant bank may perform some or all of the steps of the methodsdiscussed herein including managing the e-receipt communication programby determining identities of customer and communicating e-receipts tocustomers. In some cases, the acquiring bank or merchant bank maycommunicate the e-receipts to the financial institution server, whichthen stores the e-receipt information and/or communicates the e-receiptto the customer as well. For example, the acquiring bank or merchantbank may provide the e-receipt to the customer and then the financialinstitution administering the program may provide the e-receipt in anonline banking and/or mobile application environment for customeraccess.

In various embodiments, the database storing the participating (i.e.,enrolled) merchant and/or customer lists may be in the cloud and/or maybe stored in a proprietary cloud maintained by the financialinstitution.

While certain exemplary embodiments have been described and shown in theaccompanying drawings, it is to be understood that such embodiments aremerely illustrative of and not restrictive on the broad invention, andthat this invention not be limited to the specific constructions andarrangements shown and described, since various other updates,combinations, omissions, modifications and substitutions, in addition tothose set forth in the above paragraphs, are possible.

The steps and/or actions of a method or algorithm described inconnection with the embodiments disclosed herein may be embodieddirectly in hardware, in a software module executed by a processor, orin a combination of the two. A software module may reside in RAM memory,flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a harddisk, a removable disk, a CD-ROM, or any other form of storage mediumknown in the art. An exemplary storage medium may be coupled to theprocessor, such that the processor can read information from, and writeinformation to, the storage medium. In the alternative, the storagemedium may be integral to the processor. Further, in some embodiments,the processor and the storage medium may reside in an ApplicationSpecific Integrated Circuit (ASIC). In the alternative, the processorand the storage medium may reside as discrete components in a computingdevice. Additionally, in some embodiments, the events and/or actions ofa method or algorithm may reside as one or any combination or set ofcodes and/or instructions on a machine-readable medium and/orcomputer-readable medium, which may be incorporated into a computerprogram product.

In one or more embodiments, the functions described may be implementedin hardware, software, firmware, or any combination thereof. Ifimplemented in software, the functions may be stored or transmitted asone or more instructions or code on a computer-readable medium.Computer-readable media includes both computer storage media andcommunication media including any medium that facilitates transfer of acomputer program from one place to another. A storage medium may be anyavailable media that can be accessed by a computer. By way of example,and not limitation, such computer-readable media can comprise RAM, ROM,EEPROM, CD-ROM or other optical disk storage, magnetic disk storage orother magnetic storage devices, or any other medium that can be used tocarry or store desired program code in the form of instructions or datastructures, and that can be accessed by a computer.

Also, any connection may be termed a computer-readable medium. Forexample, if software is transmitted from a website, server, or otherremote source using a coaxial cable, fiber optic cable, twisted pair,digital subscriber line (DSL), or wireless technologies such asinfrared, radio, and microwave, then the coaxial cable, fiber opticcable, twisted pair, DSL, or wireless technologies such as infrared,radio, and microwave are included in the definition of medium. “Disk”and “disc”, as used herein, include compact disc (CD), laser disc,optical disc, digital versatile disc (DVD), floppy disk and blu-ray discwhere disks usually reproduce data magnetically, while discs usuallyreproduce data optically with lasers. Combinations of the above shouldalso be included within the scope of computer-readable media

Computer program code for carrying out operations of embodiments of thepresent invention may be written in an object oriented, scripted orunscripted programming language such as Java, Perl, Smalltalk, C++, orthe like. However, the computer program code for carrying out operationsof embodiments of the present invention may also be written inconventional procedural programming languages, such as the “C”programming language or similar programming languages.

Embodiments of the present invention are described below with referenceto flowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products. It may be understood that eachblock of the flowchart illustrations and/or block diagrams, and/orcombinations of blocks in the flowchart illustrations and/or blockdiagrams, can be implemented by computer program instructions. Thesecomputer program instructions may be provided to a processor of ageneral purpose computer, special purpose computer, or otherprogrammable data processing apparatus to produce a machine, such thatthe instructions, which execute via the processor of the computer orother programmable data processing apparatus, create mechanisms forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

These computer program instructions may also be stored in acomputer-readable memory that can direct a computer or otherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer readablememory produce an article of manufacture including instruction meanswhich implement the function/act specified in the flowchart and/or blockdiagram block(s).

The computer program instructions may also be loaded onto a computer orother programmable data processing apparatus to cause a series ofoperational steps to be performed on the computer or other programmableapparatus to produce a computer-implemented process such that theinstructions which execute on the computer or other programmableapparatus provide steps for implementing the functions/acts specified inthe flowchart and/or block diagram block(s). Alternatively, computerprogram implemented steps or acts may be combined with operator or humanimplemented steps or acts in order to carry out an embodiment of theinvention.

Those skilled in the art may appreciate that various adaptations andmodifications of the just described embodiments can be configuredwithout departing from the scope and spirit of the invention. Therefore,it is to be understood that, within the scope of the appended claims,the invention may be practiced other than as specifically describedherein.

What is claimed is:
 1. A financial institution system for providinge-receipts to customers, the system comprising: a computer apparatusincluding a processor and a memory; and a software module stored in thememory, comprising executable instructions that when executed by theprocessor cause the processor to: receive authorization from a customerfor the customer to be enrolled in a point of transaction e-receiptcommunication program; receive transaction data corresponding to atleast one transaction performed by the customer at a point oftransaction of a merchant; initiate communication, to the customer, ofan e-receipt based at least in part on the received transaction data;access a cooperating merchant list comprising information correspondingto a plurality of merchants cooperating with a financial institutionimplementing the point of transaction e-receipt communication program;and for each of the plurality of cooperating merchants, requestauthorization from the customer for transaction data associated with anytransactions performed by the customer at the cooperating merchant to becommunicated to the financial institution for the purpose of providinge-receipts to the customer.
 2. The system of claim 1, wherein theexecutable instructions further cause the processor to: requestauthorization from the customer for the customer to be enrolled in thepoint of transaction e-receipt communication program.
 3. The system ofclaim 1, wherein the transaction data is received as an e-receiptgenerated by the merchant and based on the at least one transactionperformed by the customer at the point of transaction of the merchant.4. The system of claim 1, wherein the customer's authorization for thecustomer to be enrolled in the point of transaction e-receiptcommunication program is received from an online banking session of thecustomer.
 5. The system of claim 1, wherein the customer's authorizationfor the customer to be enrolled in the point of transaction e-receiptcommunication program is received from a mobile application session ofthe customer.
 6. The system of claim 1, wherein the executableinstructions further cause the processor to: receive authorization froma plurality of enrolling merchants for enrollment in the point oftransaction e-receipt communication program; and build, based at leastin part on the plurality of enrolling merchants, a cooperating merchantlist comprising information corresponding to a plurality of cooperatingmerchants cooperating with a financial institution implementing thepoint of transaction e-receipt communication program.
 7. The system ofclaim 1, wherein the executable instructions further cause the processorto: receive customer identification information from the merchant;access a participating customer list comprising informationcorresponding to a plurality of customers participating in the point oftransaction e-receipt communication program; determine whether thereceived customer identification information corresponds to any of theplurality of customers in the participating customer list; if so,initiate communication of a confirmation message to the merchantindicating to the merchant that the customer is participating in thepoint of transaction e-receipt communication program; and wherein thetransaction data is received from the merchant in response to themerchant receiving the confirmation message.
 8. The system of claim 1,wherein the executable instructions further cause the processor to:receive customer identification information comprising loyalty accountinformation from the merchant; determine an identity of the customerbased at least in part on the loyalty account information received fromthe merchant; and wherein initiating communication of the e-receipt tothe customer is based at least in part on the determined identity of thecustomer.
 9. The system of claim 1, wherein the transaction datacorresponds to a cash transaction performed by the customer with themerchant and wherein the executable instructions further cause theprocessor to: receive identification information corresponding to anidentity of the customer; associate the transaction data with theidentity of the customer; generate the e-receipt based on the associatedtransaction data and identity of the customer; and wherein initiatingcommunication of the e-receipt to the customer is based at least in parton the determined identity of the customer.
 10. The system of claim 1,wherein initiating communication of the e-receipt to the customercomprises initiating communication of the e-receipt to an email addressassociated with the customer, to an online banking repository associatedwith the customer and to a mobile application repository associated withthe customer.
 11. The system of claim 1, wherein the executableinstructions further cause the processor to: receive, from an onlinebanking session of the customer, a request for an e-receipt associatedwith the at least one transaction; and wherein initiating communicationof the e-receipt to the customer is in response to receiving therequest.
 12. The system of claim 1, wherein the executable instructionsfurther cause the processor to: receive, from a mobile applicationsession of the customer, a request for an e-receipt associated with theat least one transaction; and wherein initiating communication of thee-receipt to the customer is in response to receiving the request.
 13. Afinancial institution system for providing e-receipts to customers, thesystem comprising: a computer apparatus including a processor and amemory; and a software module stored in the memory, comprisingexecutable instructions that when executed by the processor cause theprocessor to: receive authorization from a customer for the customer tobe enrolled in a point of transaction e-receipt communication program;receive transaction data corresponding to at least one transactionperformed by the customer at a point of transaction of a merchant;initiate communication, to the customer, of an e-receipt based at leastin part on the received transaction data; receive customeridentification information from the merchant; access a participatingcustomer list comprising information corresponding to a plurality ofcustomers participating in the point of transaction e-receiptcommunication program; determine whether the received customeridentification information corresponds to any of the plurality ofcustomers in the participating customer list; and if so, initiatecommunication of a confirmation message to the merchant indicating tothe merchant that the customer is participating in the point oftransaction e-receipt communication program; wherein the transactiondata is received from the merchant in response to the merchant receivingthe confirmation message.
 14. The system of claim 13, wherein theexecutable instructions further cause the processor to: requestauthorization from the customer for the customer to be enrolled in thepoint of transaction e-receipt communication program.
 15. The system ofclaim 13, wherein the transaction data is received as an e-receiptgenerated by the merchant and based on the at least one transactionperformed by the customer at the point of transaction of the merchant.16. The system of claim 13, wherein the customer's authorization for thecustomer to be enrolled in the point of transaction e-receiptcommunication program is received from an online banking session of thecustomer.
 17. The system of claim 13, wherein the customer'sauthorization for the customer to be enrolled in the point oftransaction e-receipt communication program is received from a mobileapplication session of the customer.
 18. The system of claim 13, whereinthe executable instructions further cause the processor to: receiveauthorization from a plurality of enrolling merchants for enrollment inthe point of transaction e-receipt communication program; and build,based at least in part on the plurality of enrolling merchants, acooperating merchant list comprising information corresponding to aplurality of cooperating merchants cooperating with a financialinstitution implementing the point of transaction e-receiptcommunication program.
 19. The system of claim 13, wherein theexecutable instructions further cause the processor to: receive customeridentification information comprising loyalty account information fromthe merchant; determine an identity of the customer based at least inpart on the loyalty account information received from the merchant; andwherein initiating communication of the e-receipt to the customer isbased at least in part on the determined identity of the customer. 20.The system of claim 13, wherein the transaction data corresponds to acash transaction performed by the customer with the merchant and whereinthe executable instructions further cause the processor to: receiveidentification information corresponding to an identity of the customer;associate the transaction data with the identity of the customer;generate the e-receipt based on the associated transaction data andidentity of the customer; and wherein initiating communication of thee-receipt to the customer is based at least in part on the determinedidentity of the customer.
 21. The system of claim 13, wherein initiatingcommunication of the e-receipt to the customer comprises initiatingcommunication of the e-receipt to an email address associated with thecustomer, to an online banking repository associated with the customerand to a mobile application repository associated with the customer. 22.The system of claim 13, wherein the executable instructions furthercause the processor to: receive, from an online banking session of thecustomer, a request for an e-receipt associated with the at least onetransaction; and wherein initiating communication of the e-receipt tothe customer is in response to receiving the request.
 23. The system ofclaim 13, wherein the executable instructions further cause theprocessor to: receive, from a mobile application session of thecustomer, a request for an e-receipt associated with the at least onetransaction; and wherein initiating communication of the e-receipt tothe customer is in response to receiving the request.
 24. A financialinstitution system for providing e-receipts to customers, the systemcomprising: a computer apparatus including a processor and a memory; anda software module stored in the memory, comprising executableinstructions that when executed by the processor cause the processor to:receive authorization from a customer for the customer to be enrolled ina point of transaction e-receipt communication program; receivetransaction data corresponding to at least one transaction performed bythe customer at a point of transaction of a merchant; initiatecommunication, to the customer, of an e-receipt based at least in parton the received transaction data receive customer identificationinformation comprising loyalty account information from the merchant;and determine an identity of the customer based at least in part on theloyalty account information received from the merchant; whereininitiating communication of the e-receipt to the customer is based atleast in part on the determined identity of the customer.
 25. The systemof claim 24, wherein the executable instructions further cause theprocessor to: request authorization from the customer for the customerto be enrolled in the point of transaction e-receipt communicationprogram.
 26. The system of claim 24, wherein the transaction data isreceived as an e-receipt generated by the merchant and based on the atleast one transaction performed by the customer at the point oftransaction of the merchant.
 27. The system of claim 24, wherein thecustomer's authorization for the customer to be enrolled in the point oftransaction e-receipt communication program is received from an onlinebanking session of the customer.
 28. The system of claim 24, wherein thecustomer's authorization for the customer to be enrolled in the point oftransaction e-receipt communication program is received from a mobileapplication session of the customer.
 29. The system of claim 24, whereinthe executable instructions further cause the processor to: receiveauthorization from a plurality of enrolling merchants for enrollment inthe point of transaction e-receipt communication program; and build,based at least in part on the plurality of enrolling merchants, acooperating merchant list comprising information corresponding to aplurality of cooperating merchants cooperating with a financialinstitution implementing the point of transaction e-receiptcommunication program.
 30. The system of claim 24, wherein thetransaction data corresponds to a cash transaction performed by thecustomer with the merchant and wherein the executable instructionsfurther cause the processor to: receive identification informationcorresponding to an identity of the customer; associate the transactiondata with the identity of the customer; generate the e-receipt based onthe associated transaction data and identity of the customer; andwherein initiating communication of the e-receipt to the customer isbased at least in part on the determined identity of the customer. 31.The system of claim 24, wherein initiating communication of thee-receipt to the customer comprises initiating communication of thee-receipt to an email address associated with the customer, to an onlinebanking repository associated with the customer and to a mobileapplication repository associated with the customer.
 32. The system ofclaim 24, wherein the executable instructions further cause theprocessor to: receive, from an online banking session of the customer, arequest for an e-receipt associated with the at least one transaction;and wherein initiating communication of the e-receipt to the customer isin response to receiving the request.
 33. The system of claim 24,wherein the executable instructions further cause the processor to:receive, from a mobile application session of the customer, a requestfor an e-receipt associated with the at least one transaction; andwherein initiating communication of the e-receipt to the customer is inresponse to receiving the request.